This code allows unattended ssh(1) processes, like the ones started by cron(8), to access the SSH keys stored by a running ssh-agent(1) (which will probably have been started in a screen(1) instance). Be sure to understand the security implications of persistent ssh-agent processes and passwordless keys.

#!/bin/sh -e
import_ssh_agent()  
  local pid
  for pid in $(pgrep -u "$LOGNAME" -x -f /bin/bash); do
    local var="$(grep -z '^SSH_AUTH_SOCK=' /proc/$pid/environ   true)"
    [ "$var" ]   continue
    eval "$var"
    export SSH_AUTH_SOCK
    break
  done
 
[ "$SSH_AUTH_SOCK" ]   import_ssh_agent
# now the script can run commands like:
ssh -o BatchMode=yes hostname command

gw-uffici.fro# sh ipv6 ospf6 nei
Neighbor ID     Pri    DeadTime  State/IfState         Duration I/F[State]
192.0.2.130     200 -341952:-44:-21   Full/BDR             00:00:08 eth0[DROther]
192.0.2.131     200 -341952:-44:-18 Twoway/DROther         00:00:05 eth0[DROther]
[...]

I am configuring a simple two-hosts redundant linux firewall. What should I use to move the virtual gateway IP between the customer-side interfaces? And why? Apparently the choices are: keepalived, ucarp, vrrpd, heartbeat and maybe even something else.

I decided to expand the scope of my blog to non-Debian subjects and non-English posts, so from now on Debian-related posts will appear in the /debian/ category (which is the only one syndicated to Planet Debian). Interested readers may subscribe to my complete feed (whose URL has not changed) or read and comment the blog in the it.fan.marco-ditri newsgroup.

My SE Linux Play Machine [1] has been online again since the 18th of March. On Monday the 11th of Feb I took it offline after a user managed to change the password for my own account (their comment was “ohls -lsa! i can change passwordls -lsals -lsa HACKED!“). Part of the problem was the way /bin/passwd determines whether it should change a password. The previous algorithm (and the one that is currently used in Debian/Etch) is that if the UID of the account that is having it’s password changed doesn’t match the UID of the process that ran /bin/passwd then an additional SE Linux check is performed (to see if it has permission to change other user’s passwords). The problem here is that my Play machine has root (UID==0) as the guest account, and that according to the /bin/passwd program there is no difference between the root account (for unprivileged users) and the bofh account (which I use and which also has UID==0). This means of course that users of the root account could change the password of my account. My solution to this was to run chcon on the /bin/passwd program to give it a context that denied it the ability to change a password. The problem was that I accidentally ran the SE Linux program restorecon (which restores file contexts to their default values) which allowed /bin/passwd to change passwords, and therefore allowed a user to change the password of my account. The semanage tool that allows changing the default value of a file context does not permit changing the default for a file specification that matches one from the system policy (so the sys-admin can’t override compiled in values). I have now fixed the problem (the fix is in my Etch SE Linux repository [2] and has been accepted for Debian/Unstable and something based on it will go into the upstream branch of Shadow. See the Debian bug report #472575 [3] for more information. The summary of the new code is that in any case where a password is not required to change the user’s password then SE Linux access checks will be performed. The long version is below: The new algorithm (mostly taken from the Red Hat code base which was written by Dan Walsh) is that you can only change a password if you are running as non-root (which means that the pam_unix.so code will have verified the current password) or if you are running as root and the previous SE Linux security context of the process is permitted access to perform the passwd operation in the passwd class (which means it is permitted to change other user’s passwords). The previous context (the context before one of the exec family of system calls was called) is used for such access checks because we want to determine if the user’s shell (or other program used to launch /bin/passwd) was permitted to change other user’s passwords - executing a privileged program such as /bin/passwd causes a domain transition and the context is different) than the program that was used to execute it. It’s much like a SETUID program calling getuid(2) to get the UID of the process which launched it. To get the desired functionality for my Play Machine I don’t want a user to change their own password as the account is shared. So I appended password requisite pam_deny.so to the file /etc/pam.d/passwd (as well as the chfn and chsh commands) so that hostile users can’t break things. The new code in /bin/passwd will prevent users from taking over the machine if my PAM configuration ever gets broken, having multiple layers of protection is always a good thing. The end result is that the Debian package and the upstream code base are improved, and my Debian Etch repository has the code in question.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472575

Share This

I have been maintaining several minor sites hosted at Dreamhost for about a year. And since over one month ago, my personal website is with them as well. And I must say, I am very pleased with them. No, not (well, not only) because they run Debian on their servers, nor because they are probably the cheapest game in town (I paid something like US$200 for a basically unlimited package , for three years), but because of their degree of responsability and personal service.
Responsability? Aren't they well-known for their network outages? Why, yes, of course - Today's example is paramount: Somebody edited the wrong firewall entry, and all of Dreamhost became unavailable. In general terms, Dreamhost has a great blog-like structured page where they inform customers of every network or server problem they have - No, you don't have to dig in to understand why your site is down: They bring it up to you. Upfront. And in a familiar, very non-formal style.
Whenever I have submitted an issue to their request tracker, I get prompt reply. Does it always solve the situation? no, by far. I'm often told to, basically, go screw myself if I really need such feature... But they are straightforward with that, they are good, nice BOFHs (if such thing ever existed), and they don't present you with corporate-minded studies backing up their solution. Yes, I know that in their servers, it's plainly their way or the highway. But hey, that's what I paid for, right?
That is what wins my heart. Yes, Dreamhost is no good for many, many tasks - including, for example, anything that requires a real RDBMS (forgodssake, they offer MySQL but not PostgreSQL, damnit! WTF!?), nor any legendary five-nines reliability. But they are great for the vast majority of the Internet sites' needs. They even exceed what a simple person like me would ever dream of.
So, my hat off to you guys. Again.
(No, and I'm not getting paid or discounted on services because of this blog post. Although maybe I should! ;-) )

I wrote a quick and dirty workaround for the recent CVE-2008-0009 and CVE-2008-0010 local privilege escalation kernel vulnerabilities. Loading this kernel module will disable the vmsplice(2) and vm86old(2) system calls, which are used by the published exploits but by very few regular programs. The code is ugly and does not support amd64 bit systems, any help is welcome.

Late last week, I visited fellow DD Tim Cutts at the Sanger Institute just south of Cambridge. I dropped off a couple more machines that the BOFHs there have kindly offered to host for Debian, and Tim offered me a quick look around their facility. Sanger plays host to a massive set of computers used for genetic sequencing and related tasks. They have a very impressive setup with thousands of machines in multiple machine rooms, connected via huge amounts of (very neatly laid!) power and networking. Oh, and multiple petabytes of disk storage, with terabytes more data generated every day. The coolest thing? Tim told me that the majority of their machines are running Debian, mostly stock installations with no special tweaks needed. Yay!

I recently discovered some perl behaviour that I cannot explain. My goal in this code was to get the matched string in $1. I see how only having a scalar for multiple possible matches (the result of g) could be a problem, but I expected to alyway get something. The effect instead is that $1 may or may not be defined, depending on apparently unrelated changes like setting the i option or changing the regexp in a way which does not alter the matched text. My test case follows.

#!/usr/bin/perl
use warnings;
use strict;
#use re 'debugcolor';
my $text = <<END;
XXWY
XXWZ
END
# $1 is defined only if I remove either of ?, g or i
my $count = $text =~ s#(XXW?Y)##gi;
print "REMOVED: <<$1>>\nCOUNT: $count\n";

Pot. Kettle. Black.

udev 0.113-1 mounts /dev noexec, and this breaks the proprietary NVIDIA driver. So far I am inclined to revert the change, but I am soliciting opinions about applications mmap'ing PROT_EXEC /dev/zero and if it is a good idea and should be allowed, or not. Feel free to post to #435250.

Happy BOFH^W sysadmin day for you! For those who aren't sysadmins, don't ask stupid questions for him/her today. Come on, just give a gift and enjoy the reaction.

By the way, Guns N' Roses - Appetite for Destruction (AFD) turned 20, six days ago so real, raw, unique! Unlike autotuned crap all over the place that we hear today from non musicians... "But Appetite was also among the last classic rock records to be mastered with vinyl in mind, to be edited with a razor blade applied to two-inch tape, to be mixed by five people frantically pushing faders at a non-automated mixing board. "We used classic instruments and classic amps," says the album's producer and engineer, Mike Clink."

Marco, if you do not want to rebuild the package you were asked to sponsor, you can just upload the binary they built. After all, it's not more of a security issue than allowing them to upload in the first place.

I voted in favour. People arguing that we should "just fix the NM process instead" are missing the whole point: even if its problems could be fixed soon (but they will not be, since many smart people have been working on it in the last few years and have not found a magic solution yet) I do not believe that becoming a Debian Developer should be easy. OTOH I like the idea of allowing full Developers to delegate co-maintenance of one of their packages like they currently do with sponsorships but without requiring them to rebuild the packages, which can become very time-consuming.

Some prominent debian-legal posters frequently make use of disclaimers like IANAL (I Am Not A Lawyer), TINLA (This Is Not Legal Advice), IANADD (I Am Not A Debian Developer). While this helps to avoid misunderstanding about the value of their opinions, I propose that a new disclaimer is used where appropriate: IAAM (I Am A Moron).

An hardware watchdog will reset the computer if the system watchdog daemon is unresponsive, e.g. because the OS has crashed. After enabling IPMI on a Linux system you can use this recipe to activate the watchdog in the BMC:

enable_ipmi_watchdog()  
  [ -e /dev/ipmi0 ]   return 1
  
  # default timeout of 10 s raised to allow some recovery time
  echo 'options ipmi_watchdog timeout=23' >> /etc/modprobe.d/watchdog
  modprobe ipmi_watchdog
  echo ipmi_watchdog >> /etc/modules
  
  apt-get install watchdog
  echo 'watchdog-device = /dev/watchdog' >> /etc/watchdog.conf
  /etc/init.d/watchdog start
 

IPMI is a standard protocol which allows out of band access to hardware features like reading sensors and error logs, turning the power on or off or accessing the serial console. This is made possible by the Baseboard Management Controller (BMC), an independent CPU which is accessed from the operating system or by sharing an Ethernet port with the OS. Most modern servers offer an IPMI 1.5 or 2.0 interface and usually loading the ipmi_si driver is all that is needed to verify if it is supported, but some may need additional parameters and/or a kernel upgrade. dmidecode is also useful to determine if the system has a BMC. After loading the ipmi_si and ipmi_devintf drivers the BMC will be accessible from Linux, e.g. using the ipmitool command. The ipmitool package will also install the ipmievd daemon, which logs events like overheating a failed fan (beware: it uses local.* syslog facility which on Debian systems is not configured by default). It is also useful to install the ipmi_poweroff driver, which will generate an ACPI power button event when a clean shutdown is requested by the BMC (you need to install acpid too). The details of accessing the BMC over an Ethernet connection varies depending on the server model and manufacturer, e.g. IBM xSeries servers are shipped with the same default IP address, username and password which means that anybody on the same L2 network (no gateway address is configured) can shut down your system: ipmitool -I lan -H 10.1.1.97 -A PASSWORD -U USERID -P PASSW0RD shell The most convenient way to experiment with IPMI is to run ipmitool shell locally and trying the available commands. These are some trivial examples:

# show the parameters for Ethernet access
lan print
# reset the system
chassis power reset
# cleanly shut down the OS and then power off the system
chassis power soft
# at the next boot, boot from the network
chassis bootdev pxe
# turn on the locator LED
chassis identify 255
# print the system event log
sel list
# read a specific sensor
# (with enough servers you could create a 3D thermal map of the room...)
sensor get "Ambient Temp"

How much of a link having a 100 ms latency I can use if I am using a 64 kB TCP window? md@wonderland:~$ units -v '64kB / 100ms' Mbps 64kB / 100ms = 5.12 Mbps 64kB / 100ms = (1 / 0.1953125) Mbps md@wonderland:~$ How big a window do I need to fill a 100 Mbps link having a 40 ms latency? md@wonderland:~$ units -v '100Mbps * 40 ms' KiB 100Mbps * 40 ms = 488.28125 KiB 100Mbps * 40 ms = (1 / 0.002048) KiB md@wonderland:~$ (I have just found the months old draft of this post, I wonder if there is something fundamentally wrong in it or I just forgot to send it...)

A data center full of servers waiting to be installed in racks which are just two millimeters too narrow.

While I usually agree that users are idiots and we know better than they do, I must recognize that the developers of the instant messaging program formerly known as GAIM are being totally wrong in their crusade against protocol icons. Hello? If I wanted a simple-minded client I would install gossip. When many people in a few days take the time to find and reply to a closed bug report then maybe they have good reasons to want a feature. And please refrain from serving us bullshit like "a preference would add too much complexity to the code", some of us actually know about pointers and switch statements. (Advanced preferences is something which the gajim developers got right. It's too bad that the Jabber transports lack many protocol features, are resource hungry, highly unstable and generally crappy.) One of the reasons for requiring native protocol icons is that each protocol has subtly different presence values, whose exact semantics are now lost. And in some situations the protocol used by your contacts has a semantic value in itself. Yes: I know that you already replied to these arguments, but you are still wrong.